For the past decade, product manufacturers have been reengineering and automating their businesses in order to survive and grow in fiercely competitive global markets. Yet the sales channels for these same companies--including inside and outside salespeople, distributors and resellers--frequently resemble their 1950's counterparts. Sales forces have only recently begun to using computers to assist in the sales process. Even if a sales force has been equipped with a laptop to assist in the sales process, in many cases salespeople still conduct business by using reams of paper catalogs, price lists, and quote sheets.
A new type of sales automation software, known as "configuration" software or "configurators", has recently emerged to assist in the product sales process. One example of known configuration software is the Calico Quote software, manufactured by Calico Technology, San Jose, Calif. With configuration software, a salesperson with a computer (often a laptop or notebook computer) engages in an information gathering session with a prospective customer, and receives information about the customer's product needs, such as budget constraints, model preferences, features desires, configuration options, etc. This information is interactively entered into the configuration software, and the software responds by providing indications that certain configurations are not valid (e.g. providing seat belts for the back seat of a 2-seat sports car that has no back seat!), computing the price of the product as configured, generating a purchase order and bill of materials ("BOM") for manufacturing, and so on.
It will come as no surprise that the sales channel has remained the final frontier for automation in many companies. Configuration software and computers are often difficult to learn and utilize. Furthermore, it is important that the configuration software is kept current, so that changes to the product, prices, configurations, options, availability, etc. are reflected in the configuration software.
Prior art configurators have traditionally used an, interpreted engine-based architecture, similar to the one depicted in FIG. 1. In such an architecture, the configuration software must have access to a configuration database, as well as other data relevant to the business, and access this data in response to user input to determine the validity and cost of a configuration. The use of an interpreted engine has its origins in expert systems and artificial intelligence technology. Execution of a set of rules and/or constraints is governed by a program, called an "engine": The engine determines what set of rules or constraints are relevant given the current state of the configuration, and allocates and deallocates memory for their execution.
The interpreted engine architecture has several drawbacks. First, configuration logic is typically expressed in a configuration language that is interpreted by a run-time engine on the salesperson's computer. Configuration languages tend to be arcane, complex, and difficult to learn. Second, although interpreted engines provide immediate feedback during application testing, they tend to require much more memory and processing resources during execution. Interpreted engines therefore tend to run slowly and are tedious to use. Third, interpreted engines tend to be more difficult to integrate with other applications on a user's computer, and often store at least part of their data in a proprietary format.
In the past, product configurator software has typically been "hard coded". That is, the configurator software is written in a programming language by computer programmers, and the constraints and information relating to the product are a part and parcel of the actual program code. Further, the data associated with the configuration is coded into the program, and can only be imported into the configurator by a skilled programmer. Because the configurators are hard coded, changes that occur to product configurations are difficult and time consuming to make. Only skilled programmers who are familiar with the code of the configurator software are able to effect the changes.
There is a need for a next-generation product configurator computer program that allows a sales engineering force--who need not also be computer programmers--to create and update a product configurator computer program. It would be desirable to have a configurator program that is easily customizable for a particular organization (i.e., have a custom user interface), and that is easily updated with new data and constraints on product configurations. It would also be desirable to have the data and constraints stored in a conventional database maintained by the enterprise, and easily read or written into the product configurator. These features would allow the product configurator program to be kept updated easily by sales engineers who are not necessarily expert computer programmers, and utilize a company's existing product database when updating the computers of the sales personnel.
One important aspect of a product configurator is the manner in which it handles "constraints". A "constraint" is a limitation of some sort placed upon some aspect of the product being sold. A good example is a customer's price range ("range constraint"). For example, the product configurator program may include a field that allows input of a range of prices that the customer may be willing to pay, for example, between $10,000 and $20,000 for a compact car. There may also be a "step size" indicating that increments of a predetermined amount, e.g., $500 are permitted, but others are not.
A range constraint then is implemented during execution of the product configurator program, by displaying a field for entry of a customer price range. If the product configuration yields a final price greater than $20,000 or less than $10,000, or an increment therebetween that is not an even $500, the product configurator should indicate an invalid condition. The invalid condition indicates that a presently selected product configuration (with certain options, features, etc.) violates the customer's price range constraint.
Typically, a constraint violation in the product configurator is indicated to a user (sales person) by a visual indication on the display screen, for example, a red flag or icon displayed in association with the data that causes the constraint violation. For example, the known Calico Technology configurator software shows invalid conditions with a red mark on a tab on the screen. The constraint violation must be corrected before a valid configuration can be determined (to obtain a final price, bill of materials, etc.).
Many prior art configurators handle constraints internally in an awkward manner. In particular, prior art configurators often include an expert system or inference engine that must continuously evaluate the state of the product configuration, typically with rules-based reasoning, in order to detect a constraint violation. Prior art configurators either require a user to create a user interface with an external visual interface tool (e.g. VISUAL BASIC), or provide a user interface with only limited flexibility. Constraints in prior art systems are typically hard-coded and therefore difficult to maintain and update.
Thus, there is a need for improved configurator software that is easier to create and maintain than prior art configurators. There is also a need for a configurator that is flexible and allows easy creation of a custom user interface that can be tailored to the needs of a particular enterprise by allowing inclusion of graphics, operational features such as radio buttons and check boxes, data entry fields, selectable choices on menus, etc., without requiring a developer or user to write program code.